Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implemented rfft!, irfft! and brfft! #222

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

favba
Copy link
Contributor

@favba favba commented Oct 20, 2021

This PR supersedes #54 .
Most of the code is the same.
It provides the same features but adds the capability of calling irfft!(c::Array{Complex},d::Integer) and rfft!(r::SubArray{<:Real} which are implicitly converted to PaddedRFFTArray. This makes it much simpler to convert code using rfft and irfft to use the in-place versions of those

In order to implement those features, we must allow PaddedRFFTArray to be initialized with a complex array, in which case the real view of the array must be reinterpreted out the complex array.
Although there is a way to make reinterpreted real-to-complex array performant (see Tim Holy's comment), it doesn't seem the same trick can be used to make reinterpreted complex-to-real arrays performant.

In this PR I'm using an internal ComplexOrRealReinterpretArray that relies on loading and storing directly from pointers to the raw data, while GC.@preserveing appropriately the underlying data.

To Do:

  • Deal with ambiguity of rfft!(a::PaddedRFFTArray,region=1:ndims(a)) and rfft!(a::DenseArray{<:Complex},d::Integer) in a better way
  • Document the new exported functions

favba added 2 commits October 20, 2021 13:54
The new functions work with a new `PaddedRFFTArray` type.
They also work with appropriately sized Compex Arrays and Real Subarrays.
…ed to solve ambiguity.

Same for `brfft!(f::PaddedRFFTArray, i::Integer)`
@codecov
Copy link

codecov bot commented Oct 21, 2021

Codecov Report

Attention: Patch coverage is 85.03937% with 19 lines in your changes missing coverage. Please review.

Project coverage is 68.14%. Comparing base (5f6f315) to head (141f60d).
Report is 56 commits behind head on master.

Files with missing lines Patch % Lines
src/rfft!.jl 85.03% 19 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master     #222      +/-   ##
==========================================
+ Coverage   62.67%   68.14%   +5.46%     
==========================================
  Files           5        6       +1     
  Lines         434      565     +131     
==========================================
+ Hits          272      385     +113     
- Misses        162      180      +18     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

src/rfft!.jl Outdated Show resolved Hide resolved
src/rfft!.jl Show resolved Hide resolved
src/rfft!.jl Outdated Show resolved Hide resolved
favba added 3 commits October 25, 2021 17:12
The transformation was not really in-place.
…rrays.

- `PaddedRFFTArray` now accepts any `AbstractArray` type, provided the strides are continuous.

- Changed some variable names to be consistent with other functions (`d` is always the length of the first dimension of the logical real array)
@kahaaga
Copy link

kahaaga commented Jan 21, 2022

Is there any progress on this PR? This would be very useful for us to have in TimeseriesSurrogates.jl, where performance of some of our methods would be improved if the in-place inverse transform irfft! would be available.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants